Draft CSS 342 Paired Programming Lab assignment #3 Winter 2014 see schedule for due date p. 1/2 
You must make all work you submit meet the grading/style rubric standards from the class website. 

Introduction: In computer forensics, one usually has to search several disk drives for evidence; seeking full copies or 
fragments of know material; so, you cannot use file size to exclude a prospect file from suspicion. The standard 
approach is to compare all consecutive bytes (cacb) from a set of target files with each possible sequence of bytes in 
every file in the set of prospects on each computer under investigation. Such comparisons can take days. For this 
assignment, you will implement a linked list based tool to facilitate an alternative approach and do timing (see timer 
sample code) comparisons to determine if, and if so, how much faster the alternative is to the "standard" approach. 

You will need to analyze the application (storing and reporting the " primeFibonacci" byte comparison data) to help 
you determine additional constraints, requirements and optimizations for your linked list based tool. If a prospect file 
is shorter than but matches a target as far as it goes, you must include it in the "suspect" collection for later, more 
detailed, consecutive bytes evaluation. Be careful of numeric overflow. 

You must create and thoroughly test a linked list based tool class (named compareList.h that includes the 
implementation compareList.cpp) to store the essential data needed to do selected "primeFibonacci" character 
comparison. Each node in the linked list must have two pointers: one pointing to data and one pointing to the next 
node. Data for each node must be stored in a class (named data.h that includes the implementation data.cpp file, both 
having full, proper doxygen coments) with, at least, the essential constructor and destructor methods as well as insert, 
remove and the comparison operator== (and operator< for data). You must name your tool unit/regression test 
program lab3testlist.cpp and it must thoroughly test your data class and list class. To submit, use sO.txt and tO.txt 
as your targets and use all provided data files as prospects (include sO.txt and tO.txt to show that your code works). 

You must name your main unit/regression test program for the sub-methods used in main lab3testmain.cpp. You 
must build and thoroughly test a program named lab3main.cpp to accomplish the following tasks: 

1. Compare a set of target files to a set of prospective files both ways (comparing only "primeFibbonacci" bytes 
and comparing consecutive bytes). Your code must skip all leading blanks at the beginning of any data files. 

2. Time and the use of the linked list tool to keep track of which files are potential matches for which of your 
search target(s) so that later, you could compare them forensically by comparing consecutive bytes. 

3. Compare the time needed to compare only "primeFibonacci" bytes to comparing consecutive bytes of the same 
targets and prospects. 

4. Provide the command line option based on the next-to-last argument "FILE" (see timerMain.cpp sample 
code) to store in a file, otherwise, print, the following comparison results for each target and prospect file: 

a. type (target or prospect), name of and number of total bytes in the file 

b. for target or prospect files, (for the primeFibonacci byte comparisons) the primeFibonacci byte 
number and contents (what is in that character) for up to nine of the first such primeFibonacci offset 
characters 

c. (for the primeFibonacci byte comparisons) for each prospect file, also clearly show which 
primeFibonacci offset characters matched the target 

d. and the percentage match between the target file and prospect file 

e. For the consecutive bytes comparison, indicate at what byte your code concluded the prospect did not 
match the target. 

You must use "new" to allocate memory dynamically for nodes and data in the linked list tool. One list stores 
data for one target or prospect file. (What attribute in your data objects will be unique and can serve as the "key" for 
insertion and removal?) 

Develop a full class for each object with the following operations: 
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1. All proper constructors and destructor (use sizeof and memset to overwrite data before deleting); 
constructor(s) to initialize a list and data node (see p. 279-280) 

2. operator^: the assignment operator to assign one object to another. See Interlude 5, especially p. 417. 

Note: try things such as "a=b= c;"in your tests. 

3. operators (==, !=, < ): Boolean equality, inequality and less than. 

4. insert a data element into a list, has Boolean return value, e.g., bool success = A.insert(someNode); 
(Note: ignore invalid arguments and return false, e.g., bool success = A.insert(INVALID_ARG); 

5. remove a data element from a list e.g., bool success = A.remove(someNode); (see pp.279-280) 

6. operator« (output) Note: operator« should not include an endl. 

You need not provide complete doxygen comments for each test function; but, for all other submitted work, use full 
class and function doxygen style comments. See Appendix I and http://www.doxygen.org for examples. At the top of 
each file submitted, you must list the author(s) and describe its purpose. You must precede each function/method 
implementation (not prototypes/signatures) in the .cpp file by a complete doxygen style comment. Clearly state any 
assumptions you make in the appropriate beginning comment block. For example, if you assume data is to be of a 
given format, document this as a pre-condition in functions that input data. You must use informative variable names 
in all signatures/prototypes. 

Your code must handle any file content data without terminating. 

You must make all operations work correctly and not crash because of data content. You may print error messages to 
cerrr but should document and deal with those errors so your program can continue running. You must have no 
memory leaks as assessed by valgrind on Linux. 

You must build thorough unit tests for each method/function/operator/constructor/destmctor to demonstrate that it 
behaves as expected under any reasonable circumstances. You must run regression tests (all tests for all code 
implemented so far) each time you build a new method/function/operator/constructor/destructor. If your code includes 
"new" statements, you must run each regression test with valgrind to ensure that you can prevent memory leaks. Unit 
and regression testing will help you build better code and the test coverage completeness will count for 10% of this 
assignment grade. 

In general, always test inside the expected range of data (elements in the middle), the boundaries of the expected range 
of data (elements at either end of the expected range of data and just before the first and just after the last element), and 
outside the expected range of data (values before the first element and after the last element). Remember to test with 
empty data, NULL, empty file, series operations such as "a=b=c"; and operations on self, such as "x = x"; 
I may run your test suit and main as well as a variety of other tests on your code (on the Linux machines). 

You must submit a zip file by the deadline (and line-numbered paper copy by next class) of at least the following: 

1. Copies of all required code (.h and .cpp files ) 

2. a typescript file showing g-i-i- -Wall and valgrind results for running all required unit/regression tests 
lab3testmain.cpp (see how to typescript in Files on Canvas) 

3. a typescript file showing g-i-i- -Wall and valgrind results for running your main application lab3main.cpp with 
any specified data 

4. any additional files needed for your application to run, including sample data files used to test your code 
(remember you must include anything needed to make your code compile and run properly in the Linux lab) 

5. additional or clarified requirements may be updated until one week before the assignment is due 

You can implement your comparison to check every feasible sequence of bytes rather than just the first non-blank 
sequence for up to 10% extra credit .This assignment expects you to use 8-bit ASCII characters. You may use 16-bit 
Unicode characters for up to 10% extra credit (if so, you must research how to use Unicode and convert all data). 

Updated: 2/8/2014 9:01 PM 



